1. Field of the Invention
This invention relates generally to computer executable cryptographic algorithms and, more particularly, to methods and computer program products for performing cryptographic provider failover from one security provider to another in a Java™ Virtual Machine (JVM).
2. Description of Background
Many software applications exploit cryptographic algorithms implemented using hardware, software, firmware, or any of various combinations thereof. It is often necessary to perform cryptographic algorithms in the context of a volatile hardware environment, with the effect that one or more cryptographic requests may fail. For example, an illustrative hardware environment may permit online and offline changes to be made to processors and other cryptographic mechanisms in a dynamic manner. These changes have the effect of disabling or enabling hardware-provided cryptographic support.
The Java™ virtual machine (JVM) is the environment in which all Java™ programs execute. It includes the Java™ Security Framework which provides cryptographic services such as key generators, ciphers and signatures. The Java™ Cryptographic Extension (JCE) is an architecture specification for cryptographic providers that register with the Java™ Security Framework to provide cryptographic services in the JVM. It should be noted herein that Java™ is a registered trademark and, for purposes of clarity and expediency, the term “Java” will be used hereinafter as a substitute for the term “Java™”.
Java Cryptography Extension (JCE) represents one example of a cryptographic environment in which hardware-provided cryptographic support may be disabled. The JCE architecture does not provide for automatic failover from one cryptographic provider to another. Java provides a Java Security Framework that includes a java.security provider list associating each of one or more service type—algorithm pairs with a corresponding preference list of one or more cryptographic service providers. In general, a failover could be implemented using any other registered provider that has different dependencies than the failing provider. Failover could be implemented using a software provider, a provider with firmware dependencies, or another hardware provider with different dependencies than the failing provider.
During JVM initialization, the Java Security Framework invokes each security provider listed in the java.security provider list. When a JCE provider initializes itself, it registers with the Java Security Framework for each serviceType.algorithm combination that it can perform. JCE security providers are available from various vendors and an installation might implement its own JCE security provider. The specific security providers in the list, and the order they appear in the list, are configurable by the installation. Some providers have external dependencies. For example, a JCE security provider might depend on certain features in a hardware platform. Another provider might have a dependency on some floating point operations engine in a software platform.
A platform with cryptographic hardware and/or cryptographic processors can be volatile. Changes in the availability of cryptographic hardware or cryptographic processors can have the effect of disabling or enabling (in part or completely) a Java security provider that exploits the cryptographic features in the platform. This can cause a provider to be unable to perform operations for a serviceType.algorithm that it registered with the Java Security Framework.
A client application that uses services provided by security providers could hard-code the provider it wants to use. However, for reasons of portability and flexibility, the client application typically does not specify a provider. Instead the application permits the Java Security Framework to select a provider based on the provider registrations. When a security provider is not specified by the client application, the Java Security Framework selects the first provider registered for the serviceType.algorithm. For example, a client application utilizes a provider by obtaining an instance of an encryption algorithm that performs a series of encryption and decryption operations. This provider is used until requests for encryption and/or decryption operations are completed or until an error occurs.
As indicated above, the JCE architecture does not provide automatic failover from one cryptographic provider to another. Consequently, if a provider is unable to perform the requested operations, the provider will throw an exception that is passed up to the application. In general, it is not advisable for the application to start over again because, unless there is a change in the status of cryptographic features on the platform, the outcome will be the same for subsequent executions of the application. This is because the provider registrations are static so the Java Security Framework will select the same provider each time.
In order for the application to try another provider, it would have to query the Java Security Framework and determine what providers have registered for the serviceType.algorithm. This is a more complex process than is generally performed in an application catch block, and requires Java security knowledge beyond the expertise of most application programmers. Accordingly, a solution is needed to provide applications the ability to leverage platform cryptographic features when available and, at the same time, provides failover to another registered provider in situations where a call to one provider has failed. An effective solution would require no customization of the Java Security Framework and no changes to client applications.